1. Field of the Invention
The present invention relates to a digital broadcast receiver, more particularly to a digital broadcast receiver that is ready to start displaying a video picture from a received digital broadcast signal a short time after being powered on, and to the startup method it employs.
2. Description of the Related Art
To offer various digital broadcasting services, besides audio and video information, digital broadcasters transmit additional information such as text or still picture data information and bidirectional interactive information based on input from the viewer. The software programs (also referred to as application programs) for executing such services have functions that are more varied and advanced than the functions used to receive conventional broadcasting. Digital broadcast receivers therefore use a general-purpose operating system (OS) to execute the programs.
In a digital broadcast receiver using an OS, software program data for each of these digital broadcasting services are read from a nonvolatile memory, where the programs are stored, into a random access memory (RAM) where the programs are executed, the reading and execution being under the control of a central processing unit (CPU). When a software program is executed, it generally starts by carrying out preparatory (initialization) processing which is necessary before the processing that implements the service functions can be carried out. Some of the functions implemented by software programs require a prodigious amount of initialization computation, which can take considerable time. The snapshot startup feature of the OS is sometimes used to shorten the startup time.
When a software program is initialized, the results of the initialization process are stored in the RAM. Data generated after the initialization process are also stored in the RAM. The data stored in the RAM during and after initialization will be referred to as working data. To prepare for a snapshot startup, the operating system saves the working data into the nonvolatile memory. Then in a snapshot startup, the operating system reads the software program data and the working data from the nonvolatile memory into the RAM, performs the minimum necessary amount of post-processing, and immediately lets the program start executing its function, skipping the initialization process. The combination of the software program data and the working data read in a snapshot startup will be referred to as snapshot data.
Even though the lengthy initialization processing of the software programs that implement the various functions of a digital broadcast receiver is skipped, however, the amount of working data that must be loaded into the RAM is large. If the digital broadcast receiver were to create a single snapshot of all the software programs it is executing, a great amount of snapshot data would have to be read from the nonvolatile memory at the next startup. This type of snapshot startup could take longer than a normal startup.
A startup method disclosed in Japanese Patent Application Publication No. 2009-176151 (page 4, FIG. 2) therefore creates separate snapshots of different programs and reads the separate snapshots in a sequence determined from data dependencies of the working data, or simply in the sequence in which the programs are needed. The time required to transfer snapshot data from the nonvolatile memory to the RAM and the time required for post-processing after the snapshot data have been read has not been considered, however, in determining the order in which the snapshots are read in conventional digital broadcast receivers. If the startup procedure includes snapshot data requiring a long transfer time or lengthy post-processing, the startup time is not necessarily reduced to any significant extent.
For example, if the snapshot data reading sequence is determined in accordance with the data dependencies of the working data so as to minimize the rewriting of data in the RAM, snapshot data that are not necessary for receiving ordinary broadcasts may be read before other more essential snapshot data. When the snapshot data transfer time is long, this can significantly delay the start of broadcast reception.
An alternative startup method, disclosed in Japanese Patent Application Publication No. 2010-140156 (page 3, FIG. 1), determines what components of the receiver are required to start a particular function and reads only the snapshot data needed by those components. When a plurality of functions are started in sequence, however, this method does not always reduce the startup time. For example, suppose that the snapshot data of function A (e.g., tuner control) and function B (decoder control) are read to start receiving a broadcast. The software program of function A has a high priority level and a relatively small snapshot data size, and its snapshot post-processing is very short. The software program of function B has a lower priority level and more snapshot data, and requires more snapshot post-processing. If the order in which the software programs are started is determined just by execution priority, then the programs of functions A and B will be started from their individual snapshots in this order (A->B). The reverse order (B->A), however, might shorten the startup time by allowing the snapshot data of function A to be read during the post-processing of function B. In some other cases, such as when the first two functions to be started are a broadcast receiving function and an electronic program guide function, the electronic program guide function cannot start during the initialization of the broadcast receiving function. The electronic program guide function and all other functions must wait until the broadcast receiving function is completely started.